Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0085/275.txt

Text File | 1997-04-16 | 15KB | 359 lines

=========================================================================

INFO-ATARI16 Digest         Fri,  2 Mar 90       Volume 90 : Issue  275

Today's Topics:
                         Bug in TURBO-C V1.0
                      Calling callgulam from TC
                          HD back-up & vault
                      Need Help with 5.25 floppy
            STE DMA sound (documentation posted) (3 msgs)
               Supra's extended partitions and tos 1.4
----------------------------------------------------------------------

Date: 2 Mar 90 10:39:54 GMT
From: sdcc6!sdcc10![e-mail]  (Mark Edwards)
Subject: Bug in TURBO-C V1.0
Message-ID: <[e-mail]>

In article <[e-mail]>
 [e-mail] (Eric C. Olson) writes:
#[e-mail] (Roland Rambau) writes:
#>[e-mail] (HC Johnson) writes:
#>->> >    #define MAX  -32768
#>->> >    main()
#>->> >    ?
#>->> >    printf("1: %d\n", MAX);
#>->> >    printf("2: %d\n", (int)MAX);
#>->> >    ?
#>->>
#>->> This is not a bug, its a feature.  MAX is not a number, its an expression.
#>->> Thus, the evaluation of MAX is a long int.  The first printf only prints
#>->K&R specify that constants are int's.  Not a long int.
#
#Like I said "MAX is not a number, its an expression."  There is an integer
#in the expression (the number 32768).  But there is also an operator (the
#unary minus).  This makes MAX an expression, not a number.  Thus the real
#question is what does K&R say integer expression are evaluated to?  I
#don't have K&R handy, but I believe it says long ints.
#
K&R, second edition, section A8.2 type specifiers offers these useful quotes:
1. If the type specifier is mission from a declaration, it is taken to be an int
2. The signed specifier is useful for forcing char objects to carry a sign; it
   is permissible but redundant with other integral types.
3. At most one of the words long or short may be specified together with int;
   the meaning is the same if int is not mentioned.

IMHO, MAX is a constant expression. Since its type is unspecified, it is an
int.  Since it is not specified as unsigned, and is an integral type, it is
therefore a signed type.  Together the conclusion that MAX is a
"const signed int MAX" when all the defaults are considered.  K&R say nothing
about the issue of long or short.  Neither does section A7.4.5 on the unary
minus operator.  The issue of long or short is probably best resolved in the
traditional manner i.e. an integer is the size of the native machine word.
This is 32 bits on a 68K.  A 8086 or 286 would be 16 bits by the same
tradition.  The native int on the 68K is then a long int, and on the Intel
it is a short int.  The expectation that short int means 16 bits and long
int means 32 bits is still meaningful.  The answer to the question is
machine architecture dependent.  For purposes of the discussion at hand, the
68K compiler should treat MAX as a signed 32 bit integer.

#Eric
#[e-mail]
#


--
Mark C. Edwards             voice:      619/586-2204
Associate Systems Analyst   unix:       [e-mail]
Matt 3:16-17,Acts 7:55-56,*John 8:17-18,*John 14:28,*Mark 13:32,
*John 20:17,*Matt 12:31-32,*John 17:20-23 (* Red letters)

------------------------------

Date: 2 Mar 90 08:46:28 GMT
From: mcsun!sunic!tut![e-mail]  (Vesterinen Arto Tapio)
Subject: Calling callgulam from TC
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail]
 (Jwahar R. Bammi) writes:
>       your example is correct. the reason it does'nt work from Turbo C
>is that Turbo C passed the arguements in registers by default, while
>gulam is expecting them to be on the stack (like the normal C stack
>frame conventions). (is there a option in TC to do this??)
>

There is a TC compiler option Standard stack frames. I tried it out, but
I still get two bombs, oh well... :-(

------------------------------

Date: 1 Mar 90 12:57:47 GMT
From: umich!sharkey!cfctech!teemc!ka3ovk!irscscm![e-mail]  (Admin)
Subject: HD back-up & vault
Message-ID: <1990Mar1.125747.17839@irscscm>

I have always been leary of using a hard drive back-up program and
have always done it by hand.  But now I've decided to change my ways
and have begun to use vault.  It seems to work very well so far but I
haven't spent enough time with to be sure yet.  What is everyone
else's opinion of vault?

One thing that has been happening to me is that occasionally my system
locks up upon selecting an item from the drop-down menu of vault.
When selecting QUIT, 3 bombs appear before the system locks.  Has this
stuff been happening to anyone else?  Is it possible I got a bad
download of vault (though it uudecoded and un-arced with no errors).

Marshall Lake
[e-mail]

------------------------------

Date: 2 Mar 90 16:16:01 GMT
From: [e-mail]  (Layne K. Jensen)
Subject: Need Help with 5.25 floppy
Message-ID: <[e-mail]>

I have finished (?) installing a 5.25-in floppy drive on my 1040ST, but
have run into what to my untrained eye appears to be a catch-22 situation
on boot-up.  I haven't seen this discussed before, so I think there must be
a simple explanation/fix.  Just for the record, this is an Epson drive.

If the floppy head isn't near track 0 at boot time, there is a vibrating
sound from the drive, and it appears that the drive is trying to seek to
track 0, but not succeeding, presumably because at that point the step rate
hasn't yet been slowed down to 6 msec.  Therefore the drive doesn't find
track 0, the computer doesn't see the TRACK 0 signal asserted, and the
computer comes to the conclusion that there is no drive B.

Even though the program to set the seek rate is now executed from the
AUTO directory, it doesn't matter, as the computer has given up.  So I can't
run a program that parks the heads on drive B.  And on re-booting the whole
problem repeats itself.

What do you do about this situation?  At this point my drive is in the open,
so I manually reset the head before powering up the drive, but once it is in
its case that won't be an option.  Is there a program available to park the
head before turning off the drive?  (I know I'll forget to run it half the
time.)  How about a program to tell the computer that there really *is* a
drive B after all, stuffing some information into a magic memory location?
I don't have any documentation that would tell me about such locations.

Do other types of drives manage to find track 0 even without the step
rate change?

Any help this would be appreciated.

Layne Jensen                           [e-mail]
Naval Ocean Systems Center             ...!sdcsvax!noscvax!jensen
San Diego, CA
--
Layne Jensen                           [e-mail]
Naval Ocean Systems Center             ...!sdcsvax!noscvax!jensen
San Diego, CA

------------------------------

Date: 2 Mar 90 04:57:49 GMT
From:
 zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!murdoch!
 astsun8.astro.Virginia.EDU![e-mail]  (Greg Lindahl)
Subject: STE DMA sound (documentation posted)
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (P E Smee)
 writes:
[ about the abacus gem books ]
>
>Does this mean they've fixed them, then?

Well, my experience with the Abacus GEM book (which is better than
their others, I think) is that the errors in the 1st edition fall in 3
areas:

1) obvious typoes, easy to correct, some only after a little
   experimentation :-(
2) errors which are copies of errors in DRI's documentation (which
   Atari sells in its devkit)
3) failing to explain which calls are only useful when GDOS is
   around. I've seen several people asking questions here who
   obviously tried to read the manual and were very confused on this
   score.

As such, I've had reasonable success using it for some small GEM
stuff, although I never tried anything with GDOS.

I haven't read the 3rd edition, but I believe a review was once posted
here? I also don't know if any of the GEM books have useful tricks
like the little routine that intercepts right-button events and turns
them into left-button events. I'd also love to see someone do a SANE
binding for GEM calls that passes pointers to structures instead of a
bunch of variables that everyone keeps in structs anyway. I managed to
cut the size of the GEM demo program source in half that way, and the
object code for the demo itself (sans bindings) shrank 35% or so. Less
bloody stack-pushing and popping for stuff that's going to get popped
and shoved into arrays anyway.

>My present favorites are the 3-volume Compute! series (one book each on
>AES, VDI, and TOS) and Katherine Peel's 'The Concise Atari ST 68000
>Programmer's Reference Guide' -- but not the first edition which was
>lacking any form of index.

Indexes do come in handy.

Greg Lindahl
[e-mail]                                  Astrophysicists for Choice.

------------------------------

Date: 1 Mar 90 15:35:27 GMT
From:
 zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!asuvax!hrc!force![e-mail]
 s.ohio-state.edu  (Richard E. Covert)
Subject: STE DMA sound (documentation posted)
Message-ID: <[e-mail]>

In article <[e-mail]>, [e-mail] (Kevin
 Clendenien) writes:
>
>    As far as having to spend a couple of hundred bucks just to get
> information on your machine, this is no different than IBM, Mac, or
> Amiga computers.  When you buy IBM and DOS, do you get a technical
> reference manual?  NO!  Sure it's available, but at a cost.  This
> same scenario is played out with both Mac and Amiga computers.  You
> can find information on the Atari line of computers without having
> to become a developer.  But, just as with the above mentioned
> computers, you will have to pay for it.  I wish information was
> free, but we all know that just ain't so.  Knowledge makes the world
> go round.  Not just in the computer field, but in every field.


Horse pukey!!!


Apple gives much better support and much of it is free!!

Just read the mac.binaries newsgroup. Apple is always posting
Macintosh Technical Notes there (which unfortunately ar BinHexed and
can't be read on UNIX machines!).

Just in the last couple of days Apple posted over a dozen Technical Notes
covering various aspects of System 7 and Hypercard and other subjects.

It makes me jealous to see some much technical information being so freely
deseminated!! And Atari Corp has the nerve to criticize a magazine reporter
for publishing programming notes on the STe! Geez, with Apple, you would have
seen the Mac Tech Notes BEFORE a reporter had a chance to "link" them.

Just goes to show you the difference between a REAL COMPUTER COMPANY and
A GAMES MACHINE COMPANY!!

And as far as buying Tech Books, there are hundreds of programming and technical
and self-help books for the Macintosh. Except for Turner's self-published books,
there hasn't been a new ST book published in the USA for 2 years!!

Argh!!! And Atari Corp has the nerve to criticize a reporter for publishing
notes about an Atari computer (actually the STe is better classified as a
games machine!. I don't need stereo sound for DTP! ).


--
 Richard E. Covert, Lead Engineer of Software Tools Group
 AG Communications Systems, Phoenix AZ   (602) - 581-4652
 TCP/IP: covertr@gtephx
 UUCP: ?ncar!noao!asuvax | uunet!zardoz!hrc | att?!gtephx!covertr

------------------------------

Date: 1 Mar 90 15:51:00 GMT
From: cs.utexas.edu!asuvax!hrc!force![e-mail]  (Richard E.
 Covert)
Subject: STE DMA sound (documentation posted)
Message-ID: <[e-mail]>

In article <[e-mail]>,
 [e-mail] (Greg Lindahl) writes:
> I have 2 books which tell me just about every software question I've
> had about the ST. Cost? $45. Sometimes I think I live in a different
> universe from everyone else. If you buy a copy of Mark Williams or
> Laser C, you get an excellent GEM manual. You can also mail-order
> books about GEM if your dealer doesn't carry them.
>
> So what's the complaint? I keep on asking what people don't like about
> current ST books. I haven't seen (yet) a single person who has
> actually read the 3rd edition Abacus GEM book, or one of the other
> good GEM books, and thought that it had lots of errors. Although some
> dealers don't carry them, they are available mail-order, and you can
> find ads for them in magazines.
>
> Where's the beef?
>
> -- greg
> Greg Lindahl
> [e-mail]                                  Astrophysicists for Choice.


Where's the beef??

Well, for one there is the still the fact that no NEW ST book has
been published in the USA for 2 years.

And the fact, that even Greg admits, that you can't buy *ANY* ST book
in the major bookstores. Just ask someone in a Waldenbooks store and you
will either get laughed at or they will mutter something about the Atari
just being a "Games Machine"

Greg, are you on a paid retainer by Atari Corp?? I have *NEVER* seen you
take a stand criticizing Atari Corp on *ANY* matter?? If you aren't,
you should ask Atari Corp to pay you !!

But, you are correct, the Mark Williams C manual is a great source of C code
for GEM AES/VDI.

But where do you go for info on programming for GDOS?? GDOS is one big black
 hole
as far as Atari Corp is concerned. It isn't covered in any C book that I have.
And programmers are all having problems writing GDOS printer drivers.

So, where's the beef?? I would answer "In Sunnyvale!!"

(At least there's lots of beef by-products emitting from Sunnyvale judging
the strength of the odors!).

Opinions are my own, but are for sale. Send MegaBucks.
--
 Richard E. Covert, Lead Engineer of Software Tools Group
 AG Communications Systems, Phoenix AZ   (602) - 581-4652
 TCP/IP: covertr@gtephx
 UUCP: ?ncar!noao!asuvax | uunet!zardoz!hrc | att?!gtephx!covertr

------------------------------

Date: Fri, 2 Mar 90 15:08+0100
From: [e-mail]
Subject: Supra's extended partitions and tos 1.4
Message-ID: <900302140852.561040@DMZRZU71-UNI-MAINZ--GERMANY>

Jim Hurley wrote:

>I just upgraded to TOS 1.4 and was wondering if I can
>now have a partition size greater than 16Meg. My SUPRA
>utilities will let me make one, but complain that GEMDOS won't
>support it. Thanks in advance.

Ignore this message. It works without problems under *tos1.4*. I am using
Supra's software with 23 Meg partitions without having any problems. The
older tos-versions, however, cannot handle Supra's extended partitions.

Hope this helps

Michael Ritzert
[e-mail]

------------------------------

End of INFO-ATARI16 Digest V90 Issue #275
*****************************************